1. Field of the Invention
This invention relates to authentication in data communication. In particular the invention relates to, but is not limited to, authenticating mobile stations and network servers communicating with each other through a network such as the Internet.
The example which will illustrate the invention is that of a mobile communication system comprising a mobile communication network and mobile stations. In this example, the network provides a service to a mobile station after authentication of the mobile station. The mobile station comprises a portable module such as a USIM card and comprises mobile equipment (handset) that is able to communicate with the network and that is able to communicate with the portable module.
2. Background Art
The present third generation (3G) standards (in particular TS 31.102 and TS 33.102) define the authentication protocol in a 3G network (known as AKA protocol, standing for Authentication Key Agreement) between the USIM card and an Authentication Center (AuC).
In this framework, the card is sent a so-called authentication request made up of several data fields:                a random challenge (RAND);        a sequence number (SQN) or a concealed sequence number (SQN⊕AK)        a message authentication code (MAC),        
AK being an anonymity key, the symbol ⊕ being the bitwise Exclusive OR, MAC being a Message Authentication Code, SQN being a sequence number that may indicate from its value whether the ongoing request is a reiterated request or not.
Upon receipt of these data fields, the card computes SQN (if required), checks the MAC and checks from the SQN that the same request has not been already sent.
To compute the SQN (if required), the USIM:                computes the anonymity key AK with a function f5 (RAND, K)        eventually retrieves the sequence number SQN by way of (SQN⊕AK) ⊕ AK=SQN.        
f5 is a key generating function used to compute AK.
K is a Long-term secret key shared between the card and the server.
Then, the card also generates an expected message authentication code XMAC using the RAND, K, SQN, an additional management field (AMF) and a authentication function f1.
Then the card compares the XMAC with the MAC which was included in the authentication request. If they are different, the card sends back to the hand-set a user authentication reject message with an indication of the cause and the card aborts the ongoing authentication procedure. In this case, the AuC may initiate a new identification and authentication procedure towards the client.
The card also verifies that the received sequence number SQN is in the correct range. The SQN may not differ more than by a predetermined amount of the SQN stored in the card. If the card considers the sequence number not to be in the correct range, it sends back to the AuC a synchronization failure message and aborts the ongoing procedure.
Such an authentication procedure is e.g. disclosed in EP-A-1 156 694. More details or explanations regarding the steps above may be found in the above-quoted standards for reference.
The MAC code (and therefore XMAC) is computed from the whole request data and the same authentication key as the requesting entity. Its role is to ensure that the request data has not been tampered during the transmission and also warrants the card that the requesting entity actually possesses the same authentication key as the card.
As the card is checking the integrity and authenticity of the data received from the server, the card computes said XMAC with a mechanism involving the data to be checked along with the authentication key K. Then, an attacker can force the utilization of the authentication key by sending to the card an authentication request with strategically chosen data. By various methods, such as side-channel and perturbation attacks, information is revealed, leading to the partial or total disclosure of the authentication key.
To be exploitable, most attacks require a given amount of authentication requests depending on the strength of the algorithm used to compute the XMAC. For each of these trials, the attacker must provide a dummy MAC (since it does not know the actual value of the key).
In known systems such as the one disclosed in the above-quoted document EP-A-1 156 694, in case of suspected tamper detection, namely whenever MAC and XMAC do not match, it is suggested to send back to the requesting entity a message asking for re-transmitting the message, then check again whether the message received anew is proper or not, and terminate the procedure in the negative. However, the system disclosed in this document does not provide any mean for keeping track of such succession of events, so that nothing may prevent the attacker, after a given authentication procedure is aborted, to reiterate another same procedure, or a series of further same procedures, until he may swindle the system to get access to protected data.